FYI - I've opened this in the AD forum, and it was suggested I move this to SCOM, as it could be that I need to tweak SCOM settings for AD.

Hello - three of our domain controllers have started to randomly report this error at different times in the day.  There have been three different occurrences from three different domain controllers.   Two of the reporting domain controllers are VM's - and one is physical.  Switch logs look clean, no reports of any issues nor any other servers having network issues.  As far as the error - it's being reported from SCOM and I'm wondering if this is a legit error or not.  The Op Master is a physical host, not a VM.  Logs on both servers look clean, no sign of network issues.  TIA!!

AD Op Master Response : Failed to ping Infrastructure Op Master 'servername.
The default gateway (172.25.x.x) is not pingable.


AD Replication Monitoring : encountered a runtime error.
Failed to write the adminDescription attribute of 'CN=servername,CN=,DC=com' to Active Directory.
The error returned was: 'The object already exists.
' (0x80071392)
Check the access permissions for this object.

Some more info on this:  

I've checked AD performance (replication) and it looks like all is well.  The question I have, is that this is also the Primary DNS server for our internal networks.  Is it possible that there could be too much traffic (ethernet) on the server and thus it's causing this alert?  So in summary, this server is the PDC Emulator, RID Master, Infrastructure Master AND the Primary DNS server.  Our network is comprised of @ 400 servers, 1300 workstations, and a lot of in-house custom applications that who knows generates how many DNS requests....

I have the exact same issue, also only seems to happen on Virtual DC's. (you using VMWare?)

The AD script mentions not being able to ping the default gateway, so i guess it has nothing to do with the physical dc. More a question of an overload vm infra? Like a shared networkcard over too many vm's or just not getting enough processing time...

AD replication monitoring probably has a different issue. it's an access problem...

Hello

I have 4 physical boxes and 4 virtual.

Most of the alerts are coming from the virtual boxes, but I have one instance where a physical box is reporting the issue too (talking to another physical box).  So I guess I cannot say mines completely virtual.  I can say this, the machines are in blades..  Is it possible that I should be digging in on that side?  (note, multiple blade chassis' are involved)

Does anyone think that this is an alert that is suitable for ignoring?  Doesn't seem like there's an obvious smoking gun, so I'm wondering if it's something that we can ignore or if we need to pursue....

TIA

for VMWare boxes I have changed from the old 'flexible' NIC to the VMXNET3 NIC with no change to the alerts.

I will be moving to the old emulated intel e1000 and if this does not resolve the issue then will decommision the VMWare dc's.

is it possible that the SCOM rule just needs to be adjusted?  not sure if it's possible...

The SCOM Agent is just reporting events logged to the eventlog on the server so the tuning the SCOM rule not to alert is simply ignoring the problem.

The problem is that VMWare based DC's regularly fail to accept LDAP bind requests for whatever reason.

• Marked as answer by Yog LiModerator Monday, May 07, 2012 9:40 AM

The SCOM Agent is just reporting events logged to the eventlog on the server so the tuning the SCOM rule not to alert is simply ignoring the problem.

The problem is that VMWare based DC's regularly fail to accept LDAP bind requests for whatever reason.

• Marked as answer by Yog LiModerator Monday, May 07, 2012 9:40 AM

This is not logged on the server, this is a SCOM script logging anything that fails in the health check.  I've reviewed the local logs on the server and this doesn't show in them.  It only shows in the "Operations Manager" log.

I realize this is a dead post, but did you see an improvement changing the network interface type to E1000?

Just hoping someone had reached a resolution to this...

Has anyone considered the server migrating to a different host in a cluster?

verify you have installed the OOMads.msi on all DC's. It is in the agent folder under HelperObjects folder

• Proposed as answer by Beigewell 2 hours 23 minutes ago

verify you have installed the OOMads.msi on all DC's. It is in the agent folder under HelperObjects folder

• Proposed as answer by Beigewell Monday, March 23, 2015 4:46 AM